[FEATURE] Add filter_link_idx to contact sensors.#2772
Open
jsw7460 wants to merge 4 commits into
Open
Conversation
Member
|
This feature has already been implemented by #2655 . |
Author
|
@Milotrince What I'm after here is a |
Milotrince
force-pushed
the
feature/contact-force-filter-link-idx
branch
from
d42940d to
6f1b2ea
Compare
Milotrince
changed the title
Member
|
I rebased your branch and updated to extend the filtering to ContactDepthProbe and KinematicTaxel as well as ContactProbe! |
Milotrince
force-pushed
the
feature/contact-force-filter-link-idx
branch
from
6f1b2ea to
1358dea
Compare
Milotrince
added
the
ready for review
Milotrince
previously approved these changes
Jul 8, 2026
ContactForceSensor now accepts filter_link_idx, mirroring ContactSensor: contacts with the sensor link whose other participant is one of the listed links are excluded from the reported force. The filter is applied on both ground-truth-update paths -- the vectorized zerocopy path (same 4D contact-vs-filter broadcast as ContactSensor, applied to the per-side contact masks before they are aggregated) and the _kernel_get_contacts_forces kernel (a small per-contact loop over the sensor's filter list). As in ContactSensor, filtered_sensor_idx gates the more expensive comparison so sensors without a filter keep the cheap path. Adds test_contact_force_sensor_filter_link_idx.
Milotrince
force-pushed
the
feature/contact-force-filter-link-idx
branch
from
6df1f03 to
82e30bd
Compare
ContactProbe, ContactDepthProbe, and KinematicTaxel now accept filter_link_idx, mirroring the Contact/ContactForce semantics: a contact with the sensor link is dropped when its counterpart link is in the filter list. The three share the counterpart check via a _func_link_is_filtered device helper threaded into both contact-depth query funcs and their kernels, and a SolverContactProbeSensorOptionsMixin so the point-cloud tactile sensors (Elastomer/Proximity), which sample a point cloud rather than solver contacts, do not expose the option. Consolidate the existing contact-force filtering while here: - the kernel now uses the shared _func_link_is_filtered helper instead of open-coding the per-contact filter flags; - the zerocopy filter masking (identical in Contact and ContactForce) is factored into _apply_counterpart_filter; - the build-time padding is factored into misc.append_filter_links_idx (used by all five sensors) and the range validation into options._validate_filter_link_idx. The filter table keeps at least one column so the no-filter case is still a valid kernel argument. Adds test_contact_probe_sensor_filter_link_idx.
"apply ... filter" didn't convey what the function does. It clears mask entries for contacts whose counterpart link is filtered out, matching the wording already used for this behavior elsewhere (e.g. the test docstring "drops contacts whose counterpart is filtered"). The self-describing name replaces the docstring, which is dropped.
…SensorOptionsMixin The mixin's only contribution over TactileProbeSensorOptionsMixin is filter_link_idx (+ its validation); nothing "solver-contact" specific lives in it - that's in the sensor implementations. Name it for what it adds: the subset of tactile probes that support counterpart-link contact filtering. The point-cloud probes (Elastomer/Proximity) intentionally stay unfiltered - they already scope via track_link_idx (an allowlist), the dual of filter_link_idx.
Milotrince
force-pushed
the
feature/contact-force-filter-link-idx
branch
from
82e30bd to
37e6118
Compare
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ContactForceSensor now accepts filter_link_idx, mirroring ContactSensor: contacts with the sensor link whose other participant is one of the listed links are excluded from the reported force. The filter is applied on both ground-truth-update paths; the vectorized zerocopy path and the _kernel_get_contacts_forces kernel.
Adds test_contact_force_sensor_filter_link_idx.
Description
ContactForceSensornow acceptsfilter_link_idx(default()), mirroringContactSensorfrom #2655: contacts with the sensor link whose otherparticipant is one of the listed links are excluded from the reported force.
Related Issue
Resolves #2771
Motivation and Context
ContactSensoralready filters its boolean by counterpart link, butContactForceSensoronly reported the total contact force on the link, with no way to scope it (e.g. "force on a foot from the ground, excluding self-contact").How Has This Been / Can This Be Tested?
test_contact_force_sensor_filter_link_idxputs a box on the floor (env 0) / a box on the floor with another box stacked on top (env 1), with twoContactForcesensors on the bottom box — one plain, one withfilter_link_idx (floor.link_start,). It asserts the filtered sensor reads ~0 in env 0 and reads only the top box's downward push in env 1, while the unfiltered sensor reads the net contact force in both.Checklist:
Submitting Code Changessection of CONTRIBUTING document.